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ABSTRACT 

A  computer  simulation  model  developed  to  study  the  operating 
characteristics  of  the  Great  Lakes  and  St.  Lawrence  Seaway  navigation 
system  Is  described.  The  model  Is  comprised  of  a  simulation  program 
(NETSIM  II),  a  report  generation  program  (PROSIM),  both  written  in 
SIMSCRIPT,  and  four  FORTRAN  support  programs  used  to  structure  selected 
Input  data  In  the  required  format  for  simulation. 

The  model  Is  addressed  Co  the  Cask  of  analyzing  Che  performance  of 
a  waterway  system  under  various  structural  and  nonstrucCural  Improveoients 
in  terms  of  delays,  congestion  and  utilization.  Major  features  of  the 
model  Include  the  ability  to  simulate  bi-directional  traffic  flows  through 
lakes,  channels,  locks  and  ports  and  the  ability  to  balance  the  supply 
and  demand  of  transportable  commodities  and  transport  equipment  units  in 
the  system. 
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FOREWORD 


The  work  described  in  this  summary  report  was  performed  by  The 
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North  Central  Division,  under  contract  number  DACW-23-72-C-0066.  The 
contract  period  is  from  July  1,  1972  to  August  31,  1973. 

This  report  is  the  third  in  a  series  of  four  volumes  documenting 

the  development  and  application  of  a  computer  model  for  the  simulation 

of  the  Great  Lakes  and  St.  Lawrence  Seaway  navigation  system.  Other 

titles  in  this  series  are  as  follows: 

Volume  1  NETSIM:  A  General  Network  Simulator 
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1.  INTRODUCTION 


A.  Great  Lakes-St.  Lawrence  Waterway  System 

In  June  of  1972,  the  Army  Corps  of  Engineers,  North  Central  Division 
entered  into  a  contract  with  the  Pennsylvania  Transportation  and  Traffic 
Safety  Center  (PTTSC)  for  the  development  of  a  simulation  model  that  would 
facilitate  a  systematic  analysis  of  the  capacity  of  the  Great  Lakes- 
St.  Lawrence  Waterway  System  (GL-SLS) .  The  development  of  this  simulation 
model  has  been  carried  out  in  three  phases: 

1.  development  of  a  Lake  Erie-Lake  Ontario  (LE-LO)  Navigation 
Simulation  model; 

2.  application  of  the  LE-LO  model  to  simulation  studies  of 
the  Welland  Canal  and  proposed  alternatives  to  the  Welland; 

3.  revision  of  the  LE-LO  model  to  include  the  capabilities 
needed  for  comprehensive  GL-SLS  system  simulations. 

This  report  is  Intended  as  a  general  summary  of  the  entire  project. 
However,  since  phases  1  and  2  were  in  large  part  steps  on  the  road  to 
phase  3,  the  report  will  focus  mainly  on  phase  3,  the  comprehensive 
simulation  model.  The  work  in  phases  1,  2  and  3  is  described  at  length 
in  [1],  [2]  and  [3],  respectively. 

The  Great  Lakes-St.  Lawrence  Waterway  System  consists  of  the  St. 
Lawrence  River,  the  five  Great  Lakes  (Lakes  Superior,  Michigan,  Huron, 

Erie  and  Ontario),  Lake  St.  Clair  and  several  connecting  channels,  includ¬ 
ing  the  Welland  Canal.  A  map  of  the  system  is  shown  in  Figure  1.  Commod¬ 
ities  moved  via  the  system  include  coal,  iron  ore,  sand,  gravel,  cement, 
grain,  petroleum  and  general  cargo.  Since  the  system  is  linked  to  the 
Atlantic  Ocean  by  the  St.  Lawrence  River,  it  serves  not  only  for  intra- 
system  commodity  movements,  but  for  trade  with  salt  water  ports  outside  the 
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system  as  well. 

The  lakes  are  relatively  uncongested  and  allow  free  movement  of 
vessels  on  them.  Width  and  depth  of  some  of  the  reaches,  however,  along 
with  traffic  regulations,  provide  significant  constraints  to  vessel 
speeds.  Further,  the  locks  in  the  St.  Lawrence  River,  the  Walland  Canal 
and  at  Sault  Ste.  Marie  are  potentially  serious  impediments  to  traffic 
flows . 

B.  Simulation  Approach  in  Analysis  of  Navigation  Improvement  - 
Historical  Development _ 

Historically,  development  of  the  current  GL-SLS  simulation  model 
dates  back  to  the  use  of  computerized  simulation  models  on  the  Inland 
waterways.  The  circumstances  leading  to  their  development  and  the  results 
of  that  research  are  reported  in  a  six-volume  technical  report  entitled 
Waterway  Systems  Simulation  [4].  The  groundwork  for  the  current  model 
was  laid  in  Volume  V  of  this  series,  entitled  Simulation  of  Multiple 
Channel  Deep  Draft  Navigation  Systems  [5].  The  model  presented  in  Volume  V 
will  be  referred  to  as  the  MCDD  model  (Multiple  Cliannel  Deep  Draft). 

One  of  the  objectives  of  the  MCDD  model  development  was  to  formulate 
a  methodology  for  assigning  vessels  between  parallel  routes.  That  research 
has  led  to  the  "experience  data  bank"  (EDB)  concept  used  in  the  GL-SLS 
simulation  model  described  herein  (NETSIM  II).  In  the  EDB  approach,  a 
special  run  of  the  simulation  model  is  made  in  which  parallel  route  choices 
are  made  at  random.  Each  time  a  vessel  traverses  such  a  parallel  route 
segment,  its  transit  time  is  recorded  along  with  data  describing  the  status 
of  the  facilities  involved  at  the  time  the  route  choice  was  made.  Such 
data  might  Include  queue  sizes  and  numbers  of  vessels  in  transit  in  each 
segment.  When  the  run  is  completed,  a  statistical  analysis  is  carried  out 
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externally  in  order  to  find  the  relationships  between  the  system  status 
parameters  and  expected  transit  time  for  each  segment. 

Hence,  expected  transit  time  formulas  are  inferred  from  the  "experi¬ 
ence  data  bank"  produced  by  the  EDB  run.  These  formulas  are  then  used  in 
the  decision  mechanism  for  subsequent  simulation  runs.  Each  time  a 
parallel  route  choice  must  be  made,  the  "Alternative  Selector"  selects  that 
route  which  offers  the  smaller  expected  transit  time. 

Another  integral  part  of  the  GL-SLS  simulation  model  which  is  heavily 
influenced  by  the  previous  research  cited  above  is  the  lock  processing. 

Locks  are  typically  the  greatest  potential  bottlenecks  in  waterway  systems; 
as  a  result,  a  great  deal  of  effort  has  been  put  into  development  of 
routines  that  will  simulate  their  operations  realistically. 

C.  NETSIM  II  -  PROSIM  Model 

The  model  used  in  the  LE-LO  simulations  was  originally  named  NETSIM/SHIP 
and  is  now  referred  to  as  NETSIM  1.  It  was  developed  specifically  for  a 
study  of  the  LE-LO  and  Welland  Canals,  and  so  did  not  have  the  capacity 
for  a  comprehensive  GL-SLS  simulation.  The  current  GL-SLS  simulation 
model  has  been  named  NETSIM  II  In  order  to  distinguish  it  from  Its  prede¬ 
cessor. 

The  primary  capability  which  has  been  added  in  order  to  give  NETSIM  II 
the  capacity  for  systems  simulation  is  a  vessel  scheduling  mechanism. 

Whereas,  NETSIM  I  required  a  schedule  of  vessel  movements  as  Input  data, 
NETSIM  II  develops  these  schedules  dynamically  based  upon  the  requirements 
for  commodity  transport.  This  dynamic  scheduling  capability  allows  study 
of  such  matters  as  vessel  fleet  requirements,  efficiency  of  various 
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scheduling  rules  and  Implications  of  hypothetical  changes  in  the  mix 
of  commodity  flows. 

NETSIM  11  has  retained  flexibility  in  two  respects.  First,  it  is 
written  in  a  powerful  language — SIMSCRIPT — with  its  logic  modularized  to 
a  great  degree.  This  means  that  modifications  to  one  aspect  of  the  model 
(e.g. ,  calculation  of  transit  times  across  lakes)  can  often  be  made  by 
altering  only  one  or  two  subroutines  and  leaving  the  rest  of  the  program 
untouched.  Second,  the  model  can  simulate  networks  of  virtually  any 
reasonable  size  and  configuration.  This  means  that  the  program  can  accom¬ 
modate  the  entire  GL-SLS  or  any  part  of  it.  Also,  the  number  of  ports, 
locks,  etc.,  to  be  Included  may  be  changed  at  will.  The  only  constraint 
on  system  size  is  the  amount  of  computer  core  memory  and  run  time  available. 
Requirements  for  auxiliary  input/output  devices  are  modest. 

The  primary  output  of  NETSIM  II  is  an  event  log,  which  consists  of  a 
separate  detail  record  for  every  event  of  interest  during  the  course  of 
the  simulation.  Here,  by  "event"  is  meant  such  status  changes  as  "vessel 
enters  berth",  "vessel  exits  lock  chamber",  "vessel  enters  queue  for  berth" 
or  "vessel  departs  reach".  These  data  in  their  raw  form  are  rather  incom¬ 
prehensible,  so  a  separate  SIMSCRIPT  program,  PROSIM,  has  been  provided  to 
process  the  event  log  data  and  produce  meaningful  reports  for  the  user. 

In  addition  to  NETSIM  II  and  PROSIM,  the  simulation  package  Includes 
a  number  of  auxiliary  programs  for  input  data  preparation.  These  facilitate 
such  tasks  as  preparation  of  vessel  fleet  data  and  arrivals  of  coimBodities 
(overland)  into  ports.  Although  they  are  quite  independent  of  the  NETSIM- 
PROSIM  model,  the  aiudliary  programs  have  been  written  in  such  a  way  as  to 
coordinate  directly  with  the  use  of  the  model. 
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D.  Concluding  Remarks 

The  following  three  sections  of  this  report  give  descriptions  of  the 
three  components  of  the  GL-SLS  simulation  package — the  NETSIM  II  program, 
the  PROSIM  program  and  the  auxiliary  support  programs.  Section  V  deals 
with  model  applici. tlons.  It  describes  both  the  LE-LO  study  using  NETSIM  I 
and  potential  applications  of  NETSIM  II  to  the  GL-SLS  and  elsewhere. 
Section  VI  presents  conclusions.  The  reader  is  reminded  that  this  is 
Intended  as  a  summary  report.  A  considerably  more  detailed  account  of 


II.  NETSIM  II  :  A  NETWORK  SIMULATOR 


As  mentioned  in  Chapter  I,  the  Great  Lakes-St.  Lawrence  Waterway 
Simulation  package  developed  in  this  research  consists  of  two  programs. 

The  first  program,  NETSIM  II,  is  the  actual  simulator  which  processes 
vessel  through  ports,  lakes,  locks  and  channels  comprising  the  navigation 
system  under  study.  The  second  program,  PROSIM,  is  the  report  generator 
which  processes  the  event  log  output  from  NETSIM  II.  The  present  chapter 
is  devoted  to  a  summary  description  of  NETSIM  II. 

A.  Model  Design  Considerations 

In  developing  this  extended  simulation  package,  considerable  emphasis 
was  placed  on  constructing  a  generalised  planning  tool.  Although  the  model 
has  been  developed  with  an  eye  towards  entire  Great  Lakes-St.  Lawrence 
Wateivay  Simulation  capability,  the  model  could  be  used  for  analysis  of 
smaller  subsystems.  Generalised  capability  has  also  meant  the  additional 
concentration  on  commodity  raevements  between  multiple  origins  and  destina¬ 
tions  as  opposed  to  simply  the  simulation  of  vessel  movements  (as  in 
NETSIM  I),  however,  its  extended  potential  can  be  attained  only  with  addi¬ 
tional  data  preparation  by  the  user. 

The  model  was  designed  and  programmed  to  be  flexible  enough  to  be 
adapted  to  any  waterv;ay  subsystem.  Tlie  model  can  accommodate  as  large  a 
system  for  study  as  is  permitted  by  hardware  capabilities.  That  is,  limits 
on  system  size  are  not  embodied  in  the  program.  The  amount  of  core  required 
depends  upon  the  number  of  lakes,  reaches,  locks,  ports,  commodities  and 
vessels  in  the  system.  As  an  example,  a  system  with  22  ports,  12  commodities, 
1,000  vessels,  5  lakes,  10  locks,  50  nodes  and  15  reaches  would  require 
about  240,000  bytes  of  core.  Requirements  for  input-output  devices  are 


modest,  even  for  large  systems. 

Flexibility  also  exists  in  the  use  of  the  computer  programming 
language  used  to  encode  the  model.  Both  NETSIM  II  and  PROSIM  are  pro¬ 
grammed  in  SIMSCRIPT  II. 5.  Although  SIMSCRIPT  requires  considerable 
programming  skill,  and  Is  not  as  widely  available  as  FORTRAN,  it  Is 
capable  of  representing  more  complex  data  structures  and  can  execute 
more  complex  decision  rules.  These  attributes  are  extremely  Important 
for  modeling  a  system  so  large  and  complex  as  the  Great  Lakes-St.  Lawrence 
Waterway.^  In  addition,  SIMSCRIPT's  English-like  readability  facilitates 
program  documentation.  Thus,  the  flexibility  of  SIMSCRIPT  can  be  summarized 
by  saying  that  in  complex  models,  SIMSCRIPT  is  able  to  produce  a  more  com¬ 
pact  model  that  requires  less  storage  space,  and  that  generally  will  be 
executed  more  rapidly. 

Flexibility  is  further  enhanced  by  the  fact  that  both  NETSIM  II  and 
PROSIM  exist  as  sets  of  subroutines  modularized  in  a  fashion  that  permits 
the  insertion,  removal  or  modification  of  any  program  segment  to  provide  a 
desired  simulation.  For  example,  the  program  can  be  used  to  study  channel 
deepening  by  reworking  the  port  and  control  routines  separately  from  all 
the  other  modules.  It  would  not  be  necessary  to  redevelop  the  entire 
program. 


B.  NETSIM  II  Input 

The  input  to  NETSIM  II  is  made  up  of  the  following  basic  data  groups 
(illustrated  in  Figure  2): 

(1)  commodity  arrival  list  at  ports; 

(2)  vessel  fleet  data; 


Slany  of  the  support  routines  do  not  require  these  characteristics  of 
SIMSCRIPT  and  hence  have  been  programmed  in  FORTRAN. 


8- 


(3)  description  of  the  navigation  facilities; 

(4)  description  of  the  navigation  network; 

(5)  run  parameters. 

The  commodity  arrival  list  at  ports  constitutes  an  external  event 

list  in  the  simulation  program  and  consists  of  data  records  specifying 

the  port  of  origin  and  the  commodity  type,  quantity,  destination  and  time 

of  arrival.  A  support  program  is  available  to  aid  the  user  in  generating 

2 

this  commodity  list. 

The  vessel  fleet  data  are  also  used  to  generate  external  vessel  intro¬ 
ductions  into  ports  at  the  start  of  the  simulation.  These  external  events 
place  vessels  at  their  home  ports  to  simulate  season  opening  and  must 
therefore  specify  the  port,  vessel  identification  and  other  vessel  attri¬ 
butes.  A  support  program  is  available  to  generate  these  vessel  introductions 

3 

from  user  supplied  fleet  data. 

The  facility  description  consists  of  a  series  of  data  records  for  each 
facility  in  the  system.  These  facilities  are  lakes,  reaches,  locks  and 
ports.  Facilities  are  described  in  terms  of  both  physical  attributes  (i.e., 
its  identification,  where  it  is  located,  etc.)  as  well  as  their  service 
times  to  process  a  vessel.  Ports,  by  virtue  of  their  special  status  as 
nodes  where  vessels  may  terminate  their  journeys,  load,  unload  and  assume 
new  journeys,  require  some  additional  information  such  as  the  specification 
of  the  extent  of  backhaul  traffic  for  each  commodity. 


2 

See  Chapter  IV,  Section  B. 
3 

See  Chapter  IV,  Section  A. 
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The  network  description  consists  of  three  matrices  which  completely 
specify  the  network  configuration.  The  first  table  is  used  in  the  simula¬ 
tion  program  as  a  route  map  for  vessels.  The  second  table  normally 
Identifies  the  type  of  facility  that  is  encountered  by  a  vessel,  although 
in  the  case  of  route  options,  that  is,  where  more  than  one  route  alterna¬ 
tive  is  available,  the  third  table  is  used  in  the  determination  of  a  vessel's 
path.  The  contents  and  the  functions  of  these  tables  of  data  are  more 
elaborately  described  in  the  next  section. 

Finally,  the  run  parameters  are  standard  to  any  simulation  run  and 
Include  such  specifications  as  the  season  length,  input-output  devices, 
and  certain  other  options. 

C.  NETSIM  II  Operation 

The  network  of  interest  is  represented  in  NETSIM  II  as  a  system  of 
links  and  nodes.  Reaches,  lakes  and  locks  constitute  the  links,  while 
ports  and  link  interfaces  are  the  nodes.  A  simulation,  then,  involves 
representing  the  movements  of  vessels  among  and  through  these  fixed 
facilities  of  the  network. 

NETSIM  II  begins  by  referencing  the  Initialization  routine  to  read 
all  Input  data  and  make  certain  basic  data  validity  checks.  If  no  data 
errors  are  discovered,  the  actual  simulation  is  begun. 

The  basic  element  which  moves  through  the  system  is  a  vessel.  The 
vessel  fleet  consists  of  a  fixed  set  of  local  bulk  carriers  plus  a  varying 
number  of  saltwater  vessels.  The  adjective  "local"  refers  to  the  fact  that 
these  bulk  carriers  never  leave  the  Seaway  for  overseas  ports.  It  should 
be  noted  also  that  they  carry  no  general  cargo.  During  simulation  their 
movements  ate  determined  dynamically  by  the  destinations  of  cargoes 
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available  at  ports.  Saltwater  vessels,  on  the  other  hand,  enter  Che 
Seaway  (from  the  Atlantic  Ocean)  with  predetermined  itineraries.  Each 
itinerary  lists  the  allowed  ports-of-call  for  the  vessel.  A  support  pro¬ 
gram  is  available  to  generate  these  itineraries  from  user  supplied  dls- 

4 

trlbutlons  of  vessel  and  tonnage  movements  in  the  system.  The  saltwater 
vessels  are  created  and  destroyed  as  they  enter  and  leave  the  system  via 
the  St.  Lawrence  River.  Associated  with  each  vessel,  both. bulk  and  salt¬ 
water,  is  a  list  of  attributes  which  carry  the  following  information: 

1.  Vessel  type  -  whether  saltwater,  dry  bulk  or  liquid  bulk 

2.  Physical  data 

(a)  Capacity 

(b)  Draft 

(c)  Horsepower 

(d)  Length 

(e)  Unloading  rate  (for  self-unloaders) 

3.  Dynamic  system  variables  such  as  current  location,  destination 

and  current  cargo. 

The  heart  of  the  simulation  program  is  the  movement  control  routine 
which  controls  a  vessel's  movement  through  the  network.  The  selection  of 
each  successive  node  in  Che  path  from  origin  to  destination  is  made  by 
reference  to  a  table  of  next  nodes  which  is  the  route  map  mentioned  earlier. 
This  is  the  basic  system  description  matrix  which  stores,  for  each  current 
node  and  final  destination,  the  next  intermediate  node  on  the  path.  The 
facility  id  table  is  Chen  referenced  by  Che  movement  control  routine  to 
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See  Chapter  IV,  Section  C. 
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identify  the  type  of  facility  encountered  by  the  vessel,  whether  it 
be  a  lock,  lake,  port  or  channel,  and  subsequently  control  is  transferred 
to  the  appropriate  link  routine  for  actual  vessel  processing.  Processing 
of  the  vessel  continues  within  the  link  routine  until  the  vessel  completes 
movement  to  the  next  most  Immediate  node  specified  by  the  physical  system 
description.  Transfer  of  control  is  then  passed  back  to  the  movement 
control  routine  which  once  again  initiates  the  loop  process  of  referencing 
system  description  tables  and  invoking  other  routines  as  prescribed  by  the 
vessel's  travel  itinerary  on  the  waterway  system. 

A  vessel's  itinerary  may  contain  alternative  route  options.  In  NETSIM 
II,  a  vessel  confronted  with  a  choice  between  two  parallel  routes  to  the 
same  destination  selects  the  route  with  the  lower  expected  transit  time. 

In  order  to  establish  the  criteria  for  estimating  such  expected  transit 
times,  a  prior  EDB  simulation  run  is  made  in  which  the  parallel  route 
selections  are  made  randomly  and  resulting  transit  times  are  recorded  along 
with  parameters  which  describe  the  state  of  the  route  segment  of  Interest. 
Then,  based  on  these  simulation  "experience”  results,  statistical  analysis 
provides  the  relationships  between  usage  parameters  (for  example,  queue 
length  at  a  lock)  for  each  parallel  segment  and  the  corresponding  transit 
times . 

In  the  normal  simulation  run,  then,  when  a  vessel  is  confronted  with 
two  or  more  route  options,  the  entry  in  the  table  of  next  nodes  is  a 
pointer  to  a  parallel  facilities  table  which  lists  the  alternatives  avail¬ 
able.  The  relationships  derived  from  the  EDB  run  are  now  used  to  determine 
the  route  with  the  lower  expected  transit  time. 


A  series  of  individual  routines  governs  Che  timing  of  the  vessel's 
movement  through  lakes,  reaches  and  locks.  The  lake  and  reach  routines 
are  rather  simple.  Transit  times  for  these  facilities  are  based  upon  an 
average  speed  with  an  adjustment  for  vessel  horsepower.  In  addition,  a 
no-passing  rule  may  be  Imposed  upon  any  reach.  Vessel  processing  in  Che 
lock  routines,  by  comparison,  is  quite  complex.  This  logic  is  the  evolu¬ 
tionary  product  of  several  years  of  simulation  studies,  both  of  shallow 
draft  Inland  waterways  and  of  the  Great  Lakes-St.  Lawrence  Waterway  System 
(see  [4]  ). 

For  simulation  purposes,  Che  locking  operation  is  broken  into  five 
segments  as  shown  In  Figure  3.  The  timing  for  each  segment  is  governed 
by  an  empirical  probability  distribution.  These  five  segments  may  further 
be  adjusted  at  user's  specification  to  represent  special  conditions.  The 
long  entry,  for  example,  can  be  adjusted  to  reflect  both  chamber  entry 
from  a  stationary  position  at  queue  and  a  moving  entry  into  chamber.  This 
detailed  micro-modeling  of  the  locking  operation  is  warranted  by  the  fact 
that  locks  present  the  greatest  potential  for  system  bottlenecks.  Simula¬ 
tion  results  can  be  quite  sensitive  to  small  changes  in  the  locking  operation. 

The  port  routines  control  the  amount  of  time  a  vessel  spends  in  port 
as  well  as  selecting  the  cargo  that  the  vessel  is  to  take  on,  if  any.  Since 
the  destination  of  a  local  bulk  carrier  is  determined  by  the  destination 
of  its  cargo,  the  dynamic  scheduling  of  these  vessels  is  in  effect  carried 
out  in  the  port  routines.  The  inventory  of  available  cargoes  at  a  port  is 
a  two-dimensional  matrix  of  tonnages  by  commodity  type  and  destination.  A 
vessel's  cargo  is  taken  from  the  matrix  cell  with  the  largest  available 
tonnage,  considering,  of  course,  only  those  cargoes  which  the  vessel  is 
capable  of  carrying.  A  certain  minimum  amount  of  cargo  must  be  available 
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Figure  3.  Locking  Time  Segments 
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to  qualify  for  loading  onto  a  vessel.  If  no  minimum  load  is  available 
at  the  port,  inquiry  can  be  made  at  one  or  more  nearby  ports  to  determine 
whether  a  suitable  cargo  is  available  there.  If  so,  that  cargo  is  ear¬ 
marked  for  the  particular  vessel  and  the  vessel  is  dispatched  to  the 
nearby  port  for  loading. 

Bulk  carriers  in  the  Great  Lakes-St.  Lawrence  Waterway  System  do,  in 
fact,  make  a  large  percentage  of  empty  backhauls.  In  order  to  reflect 
this  situation,  the  model  allows  for  specification  of  the  percentage  of 
empty  return  trips  by  port-of-origin  and  commodity.  During  a  simulation 
r'ln,  then,  each  loaded  transit  may  or  may  not  be  followed  by  an  empty 
return  trip  according  to  the  appropriate  given  probability, 

A  port  is  represented  as  liaving  a  number  of  berths  classified  into 
four  types;  general  cargo,  bulk  liquid,  grain  and  other  dry  bulk.  Time 
in  port  is  the  sum  of  four  elements:  (1)  a  small  minimum  time  to  enter 
and  exit  the  port;  (2)  actual  loading  and  unloading  time,  which  is  deter¬ 
mined  by  the  tonnage  being  transferred  and  the  transfer  rate  for  the  berth 
(or  for  the  vessel  if  it  is  a  s  if-'-nloader) ;  (3)  time  spent  in  queues 
waiting  for  a  berth  or  for  car^o  id  (4)  a  random  factor  to  account  for 
other  delays.^  In  addition  to  the  lake,  reach,  lock  and  port  routines, 
there  are  a  number  of  support  routines  to  carry  out  repetitive  tasks  such 
as  searching  tables  and  sampling  from  probability  distributions.  The 
diagram  in  Figure  4  shows  the  interactions  of  the  routines  that  comprise 
NETSIM  II. 


For  example,  the  time  to  change  berths,  weather  delays,  etc. 
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Figure  4.  NETSIM  II  Program  Flow 
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If  the  simulation  is  to  proceed  properly,  the  passage  of  simulated 
time  must  be  controlled.  This  control  is  carried  out  automatically  in 
SIMSCRIPT.  The  SIMSCRIPT  provided  timing  routine  controls  the  simulation 
clock  by  event-scheduling.  Scheduled  activities  are  ordered  chronologically 
by  the  scheduled  time  of  their  occurrence,  and  the  simulation  clock  is 
updated  to  the  next  event.  As  shown  in  Figure  4,  the  event  list  may  con¬ 
tain  exogenous  events  generated  during  simulation  by  the  lock,  port,  lake 
and  reach  routines  and  also  exogenous  events  consisting  of  commodity 
arrivals  at  ports  and  vessel  introductions  into  the  system. 

D.  NETSIM  II  Output 

NETSIM  II  provides  as  output  an  event  log  which  is  a  description  of 
all  events  that  occurred  during  the  simulation.  Each  event  description 
lists  the  time  of  occurrence,  vessel  identification,  vessel  attributes, 
the  relevant  facility  identification,  facility  attributes  and  an  event 
code  which  specifies  the  nature  of  the  event.  This  event  log  along  with 
parameters  specifying  output  options  form  the  input  to  PROSIM,  the 
statistical  report  generator. 

E.  Model  Testing  and  Calibration 

The  bulk  of  the  testing  of  the  NETSIM  II  program  was  carried  out  on 
a  hypothetical  navigation  system  network.  The  hypothetical  network  is 
very  similar  to  the  GL-SLS,  but  with  a  greatly  reduced  number  of  ports, 
locks,  reaches,  vessels  and  commodities.  Running  the  model  on  this 
smaller  system  allowed  testing  of  the  workability  of  various  calibration 
and  adjustment  factors. 
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These  calibration  factors  allow  the  operation  of  the  program  to  be 
adjusted  to  coincide  more  closely  with  that  of  the  real-world  system 
being  simulated.  Some  of  the  calibration  factors  available  in  NETSIM  II 
are  listed  below. 

1.  Vessel  loading  and  unloading  rates. 

2.  Vessel  speeds  in  reaches. 

3.  Vessel  speeds  on  lakes. 

4.  Adjustment  of  vessel  speeds  according  to  horsepower. 

5.  A  random  component  of  time  in  port.  This  is  added  to 
actual  loading  time  in  order  to  reflect  unusual  delays 
such  as  weather,  equipment  failure  or  labor  problems. 

6.  Times  required  for  various  elements  of  the  locking  operation. 

7.  Average  vessel  cargo  tonnage  as  a  fraction  of  the  vessel's 
stated  capacity. 

8.  Specification,  for  each  port,  those  other  ports  that  will 
be  considered  "nearby."  When  a  vessel  cannot  find  a 
suitable  cargo  in  its  current  port,  it  will  search  for 
cargo  in  "nearby"  ports. 

9.  Percentages  of  empty  backhaul  movements  for  bulk  vessels. 

10.  Maximum  cargo  queue  limits.  When  the  number  of  vessels  in 
a  port  waiting  for  cargo  exceeds  this  limit,  other  vessels 
will  be  sent  back  to  their  ports  of  origin  empty  rather 
than  being  allowed  to  remain  and  wait  for  cargo. 

11.  Maximum  commodity  inventory  limits.  If  the  amount  of  a 
commodity  awaiting  transit  has  built  up  past  this  limit 
in  a  port,  vessels  departing  loaded  will  be  marked  for 


empty  backhaul.  This  Is  to  ensure  that  they  will  be 
returned  to  this  port — where  they  arc  sorely  needed — 
rather  than  being  assigned  to  some  other  movement. 

The  general  workability  of  the  simulation  program  structure,  which 
includes  the  above  factors,  has  been  confirmed  through  simulation  of  the 
hypothetical  navigation  system.  Also,  a  run  has  been  made  on  a  system  very 
nearly  representing  the  GL-SLS  in  order  to  demonstrate  the  feasibility  of 
simulating  a  system  of  that  magnitude.  Time  and  data  were  not  available, 
however,  to  carry  out  a  realistic  calibration  of  NETSIM  II  for  the  GL-SLS. 


III.  PROSIM 


A  SIMULATION  PROCESSOR  FOR  NETSIM  II 


A.  PROSIM  Objectives 

The  primary  purpose  of  PROSIM  is  to  remove  Che  statisclcal  output 
generation  burden  from  NETSIM  II.  Main  factors  dictating  the  separation 
of  sCaClstlcal  processing  from  the  actual  simulation  were: 

1.  the  critical  need  to  reduce  space  requirements  for 
Che  simulation  program; 

2.  ease  of  debugging  and  error  detection; 

3.  the  ability  to  tailor  the  output  format  to  fit  the 
needs  of  the  user  without  conducting  several  reruns 
of  Che  time-consuming  simulation  phase;  and 

4.  the  creation  of  a  permanent,  detailed  record  of  the 
simulation  for  calibration  and  operational  analysis 
apart  from  the  aggregate  statistical  reports. 

These  desirable  features  were  not  obtained  without  some  sacrifice  in 
the  time  requirements.  Clearly,  some  duplicative  effort  exists  between 
Che  two  programs  with  regard  to  Input-output  processing  and  program 
structure.  Nevertheless,  the  flexibility  afforded  by  the  separation  of 
statistical  processing  from  the  simulation  phase  Is  deemed  to  be  of 
sufficient  meric  to  warrant  this  approach. 

B.  PROSIM  Description 

Figure  5  presents  a  generalized  program  flow  for  PROSIM.  The  Input 
data  requirements  for  PROSIM  are  extremely  modest  compared  to  NETSIM  II; 
apart  from  the  event  log  which  Is  usually  passed  from  the  simulation  phase 
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Figure  5.  PROSIM  Program  Flow 
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through  some  auxiliary  unit  such  as  Magnetic  tape,  they  consist  merely 
of  some  system  parameters  to  set  up  the  entity  structure  and  a  number  of 
output  options  specifying  the  type,  form  and  time  frame  for  statistical 
reports . 

Program  flow  is  controlled  by  the  event  log  processor  routine  whose 
main  function  is  to  read  and  Interpret  the  event  log  and  invoke  the  appro¬ 
priate  support  routine  to  extract  the  necessary  Information  for  generating 
user  specified  output  tables.  The  support  routines  have  been  written  with 
the  objective  of  grouping  informational  items  in  a  logical  and  meaningful 
manner  so  as  to  effect  ease  of  Interpretation  and  to  facilitate  monitoring 
control  over  certain  variables  which  reflect  the  model's  approximation  of 
the  real  world.  The  modular  structure  of  the  program  should  be  of  consid¬ 
erable  assistance  in  tailoring  segments  of  the  program  to  user  needs. 

PROSLM  provides  statistical  output  in  three  forms.  These  three  forms 
are:  (1)  generation  of  all  output  tables  at  the  end  of  the  run;  (2)  gen¬ 

eration  of  all  or  selocLed  output  tables  at  user  specified  intervals  during 
the  run;  and  (3)  puncliiiig  seiected  sL^itistics  for  further  tests  of  statis¬ 
tical  inference  at  user  specified  interv'als.  PROSIM  also  prefaces  these 
output  forms  with  a  description  of  the  waterway  s. c^em  being  analyzed  and 
other  items  whlcli  may  aid  the  user  in  interpreting  the  values  presented  in 
output  tables. 

PROSIM  provides  performance  summn  ies  for  each  category  of  system 
facilities.  .'be  output  consists  of  i. 'fteen  different  tables  detailing 
performance  results  for  locks,  port.*-',  lakes  and  reaches.  Data  in  these 
tables  may  either  be  accumulated  outi'ut  or  calculated  output.  Accumulated 
output  is  simply  Lb, at  which  is  tabulated  as  each  occurrence  takes  place 
within  the  simulation.  lor  exanipJe,  lotai  delay  is  simply  the  accumulated 
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value  for  delays  experienced  by  all  vessels.  Calculated  output  is  that 
which  results  through  some  combination  of  accumulated  data  within  the 
model  itself.  For  instance,  lock  utilization  is  a  statistic  which  is  found 
by  taking  total  lock  processing  time  (an  accumulated  value)  as  a  percent  of 
total  available  time  for  processing  (an  input  value  -  usually  the  simula¬ 
tion  length). 

In  tile  intermediate  output  form,  PROSIM  can  produce  selected  output 
displays  if  desired,  rather  than  all  fifteen  output  Cables.  This  selection 
capability  allows  generation  of  less  interval  output,  hence  speeding  up 
the  program  by  reducing  expensive  computer  operating  time.  An  instance 
where  all  output  might  not  be  desired  is  the  situation  in  which  emphasis 
was  placed  on  only  a  specific  set  of  variables  (e.g,,  locking  operations 
only!  as  opposed  to  the  complete  simulation  results.  It  should  be  noted 
that  the  final  output  form  always  produces  a  complete  set  of  output  tables, 
regardless  of  which  tabjes  (if  any)  have  been  suppressed  in  the  intermediate 
vUiLpuL  form.  in  any  case,  tiie  user  can,  through  intermediate  output, 

:  .  i.  t  c  t'ne  sai.j'Lc  sixe  for  his  analysis  without  conducting  several  separate 
‘.■■ire  ^  i  I  ill  la  t  i  'mis  . 

1;..'  use  ct  iut.cn. ediatc  output,  however,  involves  an  implicit  assumption 
liic.iut.  til!'  uKicpendcnrc  i>f  tlie  data.  That  is,  proper  application  of  many 
t  It  i  St  i  (  a  1  i.cii;  li  1  c  pii  re.s  tluit  tlio  data  used  in  the  analysis  be  independ¬ 
ent.  d!  :;'.  rv.ii  i!  1  i.ii  .a  L.indoin  vartaliie  generated  at  successive  points  in 
t  i  1C  ill  ;i  s ill'll  i L 1  on  i  r.per I iiicn t ,  ho’wever,  are  generally  autocorrelated ; 

Li  ciiLing  t  iioiii  .1:;  i  n  lcpcndent  unilcrest  imates  the  variance  of  the  correspond- 
inc,  .■..■irripli  n. iiiin  ;  I'ohin'M  can  be  avoided  by  taking  observations  at 
wincly  n^  11  (.,<.1  inter'., ils,  at  the  expense  of  a  considerable  loss  of  statis¬ 
tic. iV  po'wer,  or  I",-  dat  i  ;  I  in-n'e,  I- ition  which  unfortunately  is  Inappropriate 
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ui  ill  aiv  siiuaLi  ’IK.  An  alternative  approach  involves  the  use  of  spectral 
analysi.:;  to  measure  tlic  (ioj’rce  of  autocorrelation  and  take  it  into  account 
in  subsequent  tests  of  inference.  This  approach  has  been  documented  else¬ 
where  [6];  no  description  is  given  here.  The  use  of  this  approach  requires 
periodic  observations  on  random  variables  of  interest  (for  example,  delays). 
Tiierefore,  the  third  output  form  in  PROSIM  provides  punched  data  on  selected 
variables  to  be  used  as  input  into  subsequent  tests  of  spectral  analysis 
and  statistical  inference. 

in  summary,  the  primary  output  in  PROSIM  is  the  set  of  performance 
summary  tables  for  each  category  of  waterway  facilities  represented  in  the 
simulation  model,  Tlic  output  data  tables  for  locks  and  ports  are  the  most 
important  of  these  since  they  cf'ntain  the  most  Information.  Figures  6  and 
7  display  the  format  for  these  tables. 
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Soo 

8t  L^re 

Ca tharift 

L  Baauhr 

D  Baatrfif 

■  jjgfU- 

Elaanhow 

Iroeuols 

For  All  Vessala 

Total  overseas  cargo 

up 

200.000 

2.300,000 

dflvn 

260.000 

2,450.000 

Total  dry  bulk  cargo 

up 

2.200,000 

3,200,000 

dovn 

20,000.00u 

2,800,000 

Total  liquid  bulk  cargo 

up 

2A0,000 

700.000 

down 

50.000 

600.000 

ucillzatlnn  Rate  (2) 

57 

22 

Current  queue  length 

up 

1 

1 

down 

4 

1 

Haxlfflun  queue  length 

up 

4 

3 

down 

9 

3 

For  Vesaels  of  Lenath  I-* 399 

ft. 

Delayed  trips 

up 

215 

94 

down 

193 

101 

Average  delay 

up 

14 

6 

down 

a 

7 

Total  delay 

up 

5.660 

564 

down 

4.52! 

707 

Std.  error  for  delay 

up 

6.1 

6.7 

down 

7.4 

6.9 

Total  crips 

up 

420 

275 

down 

411 

281 

Average  transit  time 

up 

down 

72.9 

69.4 

IVy 

Total  transit  doe 

up 

30,620 

10 » 780 

down 

26,525 

10,860 

Std.  error  for  transit 

up 

20.7 

15.4 

dovm 

19.7 

15.6 

For_Ve8aela  of  Lgi\Rth  400-730  ft. 


Indicated  flguraa  are  for  Illustrative  purposes  only.  TIm  in  «lnucee.  Cargo  quantities  In  tons. 


Figure  6.  Performance  Details  for  Locks 


Indicated  figures  are  for  Illustrative  purposes  only.  Cargo  quantities  In  tons. 


IV.  SUMMARY  OF  SUPPORT  PROGRAMS 


A.  Vessel  Generation 

Vessels  are  introduced  into  the  simulated  system  via  GREAT. VESSEL 
external  event  notices.  Each  notice  specifies  the  time  that  the  event  is 
to  occur  (the  simulation  time  at  which  the  vessel  is  to  be  "created"), 
the  port  at  which  the  vessel  is  to  be  created  and  a  ntimber  of  vessel 
attributes.  Each  event  notice  is  contained  on  an  80  character  record, 
so  that  a  straightforward  method  of  creating  the  vessel  fleet  would  be  to 
keypunch  a  GREAT. VESSEL  card  for  each  vessel  in  the  fleet.  If  detailed 
data  are  available  for  the  fleet  In  question,  this  is  certainly  not  an 
unreasonable  approach. 

The  Vessel  Generation  Program  has  been  provided  to  generate  a  fleet 
with  a  desired  mix  of  vessels  without  necessitating  the  keypunching  of 
each  individual  GREAT. VESSEL  card.  It  also  provides  an  easy  means  for 
varying  the  number  of  vessels  in  the  fleet  and  for  experimenting  %d.th 
varying  the  mix  of  vessel  attributes.  The  program  is  written  in  FORTRAN. 

For  each  of  the  three  vessel  classifications  (dry  bulk,  liquid  bulk 
and  saltwater)  the  user  must  supply  a  pool  of  representative  vessels.  The 
vessels  for  the  fleet  will  then  be  selected  from  these  three  pools  accord¬ 
ing  to  user-assigned  probabilities.  The  user  also  provides  the  probabilities 
for  choosing  the  port  at  which  a  vessel  of  a  given  class  will  be  created. 

A  sequence  of  input  cards  dictates  (deterministically)  how  many  vessels  of 
each  class  will  be  created  at  what  times. 

The  GREAT. VESSEL  cards  produced  by  the  Vessel  Generation  Program  mi^t 
easily  be  supplemented  with  some  keypunched  cards.  This  could  be  done  in 
order  to  introduce  a  few  special  vessels  into  the  system  at  particular  ports. 


B.  Commodity  Arrivals 


Overland  commodity  arrivals  Into  ports  In  the  simulated  system  are 
triggered  by  COM. ARRIVAL  external  event  notices  in  NETSIM  II.  The 
Commodity  Arrival  Generation  Program  provides  a  convenient  means  of  pro¬ 
ducing  the  COM. ARRIVAL  event  notices  as  long  as  the  pattern  of  commodity 
arrivals  is  invariant  over  time.  The  program  is  written  in  FORTRAN. 

The  user  must  supply  the  mix  of  commodities  that  will  arrive  in  the 
ports  periodically.  This  "mix"  involves  four  pieces  of  information  for 
each  module  of  cargo: 

(1)  the  commodity  type 

(2)  the  port  into  which  it  is  arriving 

(3)  its  destination 

(4)  the  quantity  (tonnage). 

Once  the  mix  of  arrivals  is  defined,  it  is  reproduced  in  COM. ARRIVAL 
event  notices.  An  event  notice  is  produced  for  each  time  the  user 
specifies  that  commodity  arrivals  should  occur.  For  example,  if  the 
arrival  mix  data  specify  an  average  daily  arrival  pattern,  then  one  might 
want  arrivals  to  occur,  say,  at  midnight  of  each  day  (simulation  times  0, 
1440,  2880,  .  .  .),  If  a  smoother  arrival  schedule  is  desired,  then  more 
frequent  arrivals  in  smaller  quantities  would  be  called  for.  Any  schedule 
can  be  specified  so  long  as  the  mix  which  is  to  arrive  at  any  one  time 
does  not  vary.  If  this  mix  is  to  vary  during  the  period  of  a  single  simu¬ 
lation  run,  either  a  modified  arrival  generation  program  or  multiple  runs 
of  this  program  would  be  required. 

C.  Itinerary  Generation 

Saltwater  vessels  enter  the  system  via  the  St.  Lawrence  River  with 
predetermined  itineraries.  The  Itinerary  Generation  Program  is  an  auxiliary 
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FORTRAN  program  which  produces  these  required  itineraries  for  use  in 
NETSIM  II.  An  itinerary  consists  of  a  sequence  of  ports  of  call  and, 
for  each  port,  a  specification  of  the  fraction  of  the  vessel's  inbound 
tonnage  to  be  unloaded  and  the  fraction  of  the  vessel's  capacity  to  be 
loaded.  The  latter,  of  course,  is  the  maximum  amount  to  be  loaded;  in 
any  individual  case,  If  the  full  specified  amount  of  cargo  is  not  avail¬ 
able  at  the  port,  only  the  amount  available  will  be  loaded. 

Itineraries  are  built  randomly  based  upon  user-supplied  empirical 
distributions  which  describe  actual  saltwater  vessel  movements  in  the 
Great  Lakes-St.  Lawrence  Waterway  System.  The  generated  itineraries  must 
reflect  the  observed  vessel  movement  patterns  as  well  as  providing  capacity 
for  observed  commodity  movements. 

The  itineraries  are  written  as  output  records  which  are  in  turn  used 
as  input  to  NETSIM  II.  Each  tisne  a  saltwater  vessel  is  introduced  into  the 
system,  NETSIM  II  reads  in  the  next  itinerary  and  assigns  it  to  that  vessel. 
Itineraries  are  assigned  independently,  without  regard  for  a  vessel's 
capacity,  speed  or  national  origin. 

D.  EPS  Pr<  cessing 

The  EDB  processing  program  is  a  FORTRAN  program  that  is  used  to  process 
the  "experience  data  bank"  (EDB)  generated  during  an  EDB  simulation  of 
parallel  route  facilities  In  a  system.  In  NETSIM  II,  a  vessel  confronted 
with  a  choice  between  two  or  more  parallel  routes  to  the  same  destination 
selects  the  route  with  the  lower  expected  transit  time.  In  order  to 
establish  the  criteria  for  estimating  such  expected  transit  times,  an  EDB 
simulation  run  is  made  in  which  the  parallel  route  selections  are  made 
randomly  and  resulting  transit  times  are  recorded  along  with  certain  usage 
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parameters  (such  as  lock  queue  size)  which  describe  the  state  of  the 
route  segment  of  interest.  The  EDB  processing  program  processes  these 
records  and  arranges  the  usage  parameters  for  each  parallel  segment  with 
their  associated  vessel  transit  times  so  that  they  can  be  input  directly 
to  statistical  analysis  (commonly  a  canned  regression  program). 


V.  MODEL  APPLICATIONS 


This  section  sunimarizeb  the  Ui’plicatiou  of  KEISIM  I  to  the  LE-LO 
Navigation  System  and  discustiCi:.  liie  potentials  o£  the  NCTSIM  II-PROSIM 
model  for  simulation  studies  of  the  GL-SLS  and  other  waterways.  N'ETSIM  I 
alternatively  referred  to  as  the  LE-LO  sLr;ulation  model  in  this  report, 
was  used  in  the  simulation  studies  of  tlic  Welland  Canal  and  proposed 
alternatives  to  the  Welland.  To  date,  the  NETSIM  II-PROSIM  model  has  not 
been  applied  to  any  existing  wateru'ay  although  a  number  of  runs  on  hypo¬ 
thetical  configurations  liavo  been  performed.  Tlie  primary  objective  of 
this  chapter  is,  then,  to  draw  focus  upon  the  type  and  character  of  infer 
mation  derived  from  the  use  of  ear.h  simulation  model,  rather  than  upon 
detailed  documentation  of  each  simulation  run. 

A.  Lake  Erie-Lake  Ontario  Navigation  Study 

1.  Scope  and  Objectives  of  ttie  Study 

The  purpose  of  this  study  was  to  utilize  the  NETSIM  I  model  in 
simulation  studies  of  the  Welland  Canal  and  proposed  alternatives  to  the 
Welland.  Its  scope  encompassed  tne  following  subtasks: 

1.  to  establish  the  expected  limits  of  service  of  the 
existing  Welland  Canal, 

2.  to  establish  the  expected  incremental  increase  in  service 
potential  of  the  existing  Welland  Canal  under  assumptions 
of  improved  locking  procedures  and  an  improved  traffic 

control  system. 
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3. 


to  determine  the  expected  performance  of  a  combined 
Welland-Nlagara  system  with  configuration  alternatives 
of  four,  five  and  six  locks  in  series  in  the  Niagara 
Canal  in  combination  with  the  existing  Welland  Canal, 

4.  to  examine  the  expected  performance  of  a  replacement  for 
the  Welland  Canal  consisting  of  a  series  of  four  super 
locks  plus  a  guard  lock  towards  the  mouth  of  Lake  Erie. 

These  configurations  were  subjected  to  current  and  anticipated  levels 
of  traffic,  fleet  composition,  ship  size,  and  operating  procedures.  The 
primary  measure  of  system  performance  was  system  transit  time.  This 
variable  reflects  both  the  service  levels  provided  by  system  facilities 
and  any  delays  that  occur  due  to  congestion.  In  addition,  measures  of 
lock  utilization,  lock  processing  time,  and  time  spent  in  queues  were  taken 
so  that  the  system  response  could  be  stated  in  terms  of  delays  due  to 
congestion  and  lock  utilization.  However,  no  analysis  of  the  effects  of 
delays  and  system  congestion  upon  demand  was  undertaken.  Hence,  the 
emphasis  of  the  study  was  placed  upon  determining  what  configurations  of 
navigation  facilities  are  required  to  meet  the  prospective  transportation 
demand  and  to  enable  the  network  to  function  effectively  as  a  system. 

2.  LE-LO  Navigation  System 

Passage  between  Lake  Erie  and  Lake  Ontario  is  accomplished  through  the 
Welland  Canal  which  stretches  between  Port  Weller — a  man-made  harbor  serving 
as  the  Lake  Ontario  entrance  to  the  canal — and  Port  Colbome  on  Lake  Erie, 
a  distance  of  twenty-seven  miles.  Its  eight  locks,  three  of  them  twinned, 
have  a  total  lift  of  three  hundred  twenty-six  feet  to  the  level  of  Lake  Erie. 
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Its  minimum  channel  width  in  the  open  reaches  is  two  hundred  feet  while 
its  locks  can  accommodate  a  vessel  of  maximum  dimensions  730'  x  75 '6". 

As  the  canal  traverses  a  densely  populated  area,  numerous  bridges  must 
be  lifted  for  a  ship  to  transit;  however,  in  1973,  ships  began  to  utilize 
the  Welland  Bypass,  a  new  section  which  bypasses  the  city  of  Welland  and 
is  free  of  all  bridges.  The  location  and  extent  of  this  system  are  shown 
in  Figure  8. 

Vessel  transit  through  the  Welland  Canal  is  supervised  by  a  semi- 
automated  traffic  monitoring  and  control  system  installed  by  the  St. 

Lawrence  Seaway  Authority  in  1965.  This  traffic  control  system  permits 
the  exact  location  of  each  vessel  to  be  monitored  by  sensors  placed  at 
strategic  locations  in  the  canal.  This  information  is  supplemented  by 
closed  circuit  television  cameras  with  which  the  controller  can  see  the 
status  of  lock  components  and  ship  gear.  Information  is  transmitted  to 
the  vessel  by  status  lights  as  well  as  radio  and  loud  speaker  so  that 
it  may  transit  with  a  minimum  of  delay  [7,  8]. 

3.  System  Design  Alternatives 

Six  alternative  system  configurations  were  simulated  in  this  study. 
Tnree  of  the  alternatives  consisted  of  a  single  channel,  the  Welland 
Canal,  while  the  rest  consisted  of  two  parallel  channels  in  a  coidilned 
Welland-Niagara  system.  The  single  channel  configurations  were:  (1) 
the  existing  Welland  Canal;  (2)  the  non-structurally  Improved  Welland 
Canal;  and  (3)  a  structurally  improved  Welland  Canal  consisting  of  a  series 
of  five  locks^  of  greater  lift  and  1200’  x  110’  dimensions.  The  two-channel 


^Includes  a  guard  lock. 
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systems  were  configurations  of  four,  five,  and  six  locks  in  series  in 
the  proposed  Niagara  Canal  In  combination  with  the  existing  Welland. 

For  the  purposes  of  this  study,  the  Welland  Canal  was  modeled  as  a 
set  of  six  entities  where  operations  within  each  entity  were  inferred 
rather  than  specifically  modeled.  Recent  traffic  data  [9]  for  the  canal 
were  used  to  establish  relationships  between  vessel  transit  time  and  the 
state  of  the  canal  (number  of  ships  in  the  canal,  etc.).  Transit  times 
through  the  canal  were  then  derived  in  the  simulation  as  a  polynomial 
function  of  the  state  of  the  canal. 

4.  Simulation  Runs 

The  basic  methodology  for  the  Welland-Niagara  simulation  experiments 
entailed  the  division  of  traffic  between  parallel  facilities.  This  factor 
dictated  the  use  of  the  model's  EDB  channel  choice  mechanism;  thus,  EDB 
simulation  runs  were  performed  on  each  Welland-Niagara  configuration  to 
derive  ETT  functions. 

The  simulation  run  for  the  existing  Welland  Canal  under  a  1971  traffic 
load  served  as  the  base  run  in  establishing  calibration  values  for  the 
model's  parameters.  Siibsequent  simulations  subjected  each  network  to 
increasing  transport  demand  from  1980  through  to  2030,  if  necessary,  in 
five-year  increments  up  to  year  2000  and  in  ten-year  increments  thereafter. 
Each  simulation  was  examined  for  signs  of  saturation  to  determine  if  the 
next  higher  level  of  demand  experiment  was  necessary. 

Transport  demand  was  represented  in  the  input  data  by  two  factors , 
projected  levels  of  traffic  and  traffic  composition.  Two  estimates  for 
each  of  the  projected  levels  were  given  in  order  to  allow  for  the  uncertainty 


of  future  demand.  Traffic  composition  was  allowed 
period  and  it  reflected  an  estimated  trend  towards 
Tables  1  and  2  show  the  actual  data  used  for  these 


to  vary  over  the  study 
larger  vessel  size, 
two  factors. 


TABLE  1.  AVERAGE  DAILY  VESSEL  TRANSITS  (ships/day) 


Traffic 
Level  "A" 


1970 

25.50 

1980 

26.50 

1985 

27.00 

1990 

27.50 

1995 

28.00 

2000 

28.50 

2010 

29.50 

2020 

30.90 

2030 

32.20 

Note: 

Data  for  1970 
projected. 

Traffic 
Level  ''B" 

25.50 

27.40 

28.55 

29.70 
31.15 
32.60 

35.70 
39.80 
44.30 

actual,  for  the  others  are 


TABLE  2.  FLEET  COMPOS ITICW-PERCENTAGE  DISTRIBUTION  BY  CLASS 


Class  I  Class  II  Class  III 

(l'-399«)  (400* -730')  C731'-1150') 


1970 

30.00 

70.00 

0.00 

1980 

23.30 

74.70 

2.00 

1985 

19.85 

74.60 

5.55 

1990 

16.40 

74.50 

9.10 

1995 

14.00 

73.45 

12.55 

2000 

11.60 

72.40 

16.00 

2010 

9.60 

68.60 

21.80 

2020 

6.60 

65.00 

28.40 

2030 

5.30 

60.00 

34.70 

Note:  Data  for  1970  are  actual,  for  the  others  are  projected. 
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5.  Results  aau  Conclusions 


Some  specific  simulation  results  are  enumerated  below. 

1.  All  twin-canni  simulations  used  a  single  set  of  locking  data. 

Under  tliese  conditions,  no  statistical  differences  could  be 
estaillshed  a-;:ong  any  of  the  three  configurations.  Changes 
in  locking  data  among  the  various  networks  could  revise  this 
result. 

3 

2.  Practical  capacity  of  the  existing  Welland  Canal  was  achieved 
between  1990  and  2010  under  the  projected  traffic  levels. 

3.  Nonstructural  improvements  to  the  Welland  Canal  leading  to  a 
reduction  In  the  lock  cycle,  increased  the  capacity  of  the 
system  by  five  to  ten  years  under  projected  traffic  levels. 

4.  For  Lii'*  structurally  improved  Welland  Canal  (replacement  of  the 
exist  ii';’,  seven  860'  x  80'  locks  by  four  1200'  x  110*  locks), 

a  set  of  canal  transit  time  curves  for  varying  lock  service 
rates  was  developed.  Tlie  capacity  of  this  system  was  found 
to  be  e;-.'  i  ei;c.!y  sensitive  to  lock  service  times. 

The  most  clcar-cut  result  of  this  simulation  study  is  that  the  twin- 
canal  conf iguiMt ions  are  able  to  provide  better  service  over  a  longer 
period  of  tiru'  Llmu  i he  single  Welland  configurations.  This  is  plctorially 
demonstrate  i  In  i iguj-es  9  and  10  showing  the  average  canal  transit  time 
under  eacli  pi.o  jc .  '  ,.(i  Lrafric  level.  The  Welland-Niagara  configurations 
distincLly  refjec!  c/.ce.ss  capacity  through  the  end  of  the  current  millennium 
and  in  fact  any  ul  the  four-,  five-,  or  six- lock  Niagara  Canals  in  combina¬ 
tion  with  tlic  v'ell.md  wi'uid  perform  equally  well  under  projected  traffic 
up  to  year  201a. 


3 

Practical  capac.  jiy  wan  defined  in  this  study  as  that  point  at  which  the 
system  r<  arh,  •,  ,  p.,  T' ■  nt  its  theoretical  maximia  capacity. 
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W  =  EXISTING  WELLAND 
Wl  =  IMPROVED  WELLAND 
Vy2  =  WELLAND  SiJPERLOCKS 


1 


WN6  =  WELLAND  -  SIX  LOCK  NIAGARA 
WN4  =  WELLAND  -  FOUR  LOCK  NIAGARA 


Figure  10.  Transit  SuTjnary  Under  Traffic  Level 


B.  Great  Lakes-St.  Lawrence  Waterway  Simulation 


1.  Introduction 

'rile  validity  of  a  simulatic  is  a  measure  of  the  extent  to  which  it 
satisfies  its  design  objectives,  In  the  case  of  the  NETSIM  II-PROSIM 
model,  the  design  objective  was  the  development  of  a  model  with  capa¬ 
bilities  for  comprehensive  GL-SLS  system  simulations.  Thus,  assurance  of 
validity  requires  the  following: 

(a)  The  model  must  be  shown  capable  of  simulating  a  "representative" 
configuration  of  the  GL-SLS  system  consistent  with  the 
specified  applications. 

(b)  The  theoretical  structure  of  the  model  including  all  the 
assumptions  must  appear  reasonable  in  relation  to  the  real 
world  phenomenon  being  simulated. 

(c)  The  model  must  be  shown  to  measure  what  it  purports  to 
measure . 

Since  properties  (b)  and  (c)  of  the  simulation  model  are  treated  in  the 
accompanying  volume  [3],  this  section  will  be  restricted  to  a  summary 
description  of  a  simulation  experiment  of  the  GL-SLS  system. 

2.  Simulation  Methodology,  Data  and  Results 

Tlie  simulation  encompassed  a  representative  GL-SLS  configuration 
consisting  of  18  ports,  9  locks,  15  reaches  (channels)  and  the  five 
Great  Lakes.  Commodities  in  trade  were  grouped  into  seven  categories. 
Vessels  were  aggregated  into  three  types:  dry  bulk  transporters,  liquid 
hulk  tankers  and  .saltwater  vessels.  These  principal  entitles  in  the 
simulation  run  are  listed  in  Table  3. 
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TABLE  3.  ENTITIES  IN  GL-SLS  SIMULATION  USING  NETSIM  II-PROSIM  MODEL 


a* 

Ports 

b. 

Locks 

1. 

Duluth,  Superior,  Port  Arthur 

1. 

St.  Lambert 

2. 

Marquette,  Sault  Ste.  Marie 

2. 

Cote  Ste.  Catherine 

3. 

Escanaba 

3. 

Upper  and  Lower  Beauharnols 

4. 

Milwaukee 

4. 

Snell 

5. 

Chicago 

5. 

Eisenhower 

6. 

Gary,  Indiana  Harbor 

6. 

Iroquois 

7. 

Muskegon 

7. 

Poe  (at  Sault  Ste.  Marie)* 

8. 

Alpena  (Lake  Huron) 

8. 

Other  Sault  Ste.  Marie  locks 

9. 

Detroit,  Windsor 

represented  as  one  lock* 

10. 

Toledo 

c. 

Reaches 

11. 

Cleveland 

1. 

15  connecting  channels  and  rivers 

12. 

Buffalo 

13. 

Inland  Waterways 

14. 

U.  S.  Coastwise 

d. 

Lakes 

15. 

liamilton 

1. 

Superior 

10. 

Toronto 

2. 

Huron 

17. 

Montreal 

3. 

Michigan 

18. 

Atlantic  (overseas) 

4. 

Erie 

5. 

Ontario 

e. 

Welland  Capal 

^Formed  a  parallel  lock  system. 


f .  Conimodit  j  es 

1.  Grain  (corn,  soybeans,  wheat,  other  grain) 

2.  Coal 

1.  Cornell t,  atone,  sand  and  gravel 

4.  Iron  Ore 

5.  Other  bulk  (other  ores,  pulp  and  paper  and  other  bulk) 

6.  Petroleum  (fuel  oil,  gasoline,  and  other  petroleum  products) 

7.  Gereral  cargo  (iron  and  steel,  other  primary  metals,  chemicals, 
food,  transportation  equipment,  machinery,  other  manufactured  goods) 
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The  simulation  was  conducted  for  a  one-month  period  beyond  initial 
warmup  time.  A  total  fleet  of  848  vessels  including  720  bulk  transporters 
was  introduced  into  the  system.  A  port-to-port  origin  and  destination 
matrix  of  the  seven  types  of  commodity  movements  was  arbitrarily  constructed 
and  introduced  through  ports  as  daily  arrivals.  The  cargo  input  data  summary 
is  shown  in  Table  4. 


TABLE  4.  INPUT  CARGO  SUMMARY  FOR  THE  GL-SLS  SYSTEM  SIMULATION 


Cargo  Type 

Annual  Tonnage 

Average  Monthly  Tonnage 

1. 

Grain 

10,717,582 

893,132 

2. 

Coal 

43,315,220 

3,609,601 

3. 

Cement,  etc. 

42,880,045 

3,573,337 

4. 

Iron  Ore 

80,530,977 

6,710,915 

5. 

Other  dry  bulk 

6,967,027 

580,586 

6. 

Liquid  Bulk 

9,926,752 

827,229 

7. 

General  Cargo 

14,282,337 

1,193.195 

TOTAL 

208,619,940 

17,384,995 

In  addition  to  these  data,  all  other  data  such  as  port  turnaround  time 
factors,  locking  distributions  and  reach  and  lake  transit  times  were  hypo¬ 
thetically  constructed  since  a  complete  and  accurate  data  base  was  not 
available  at  the  time  of  the  experiment. 

The  simulation  results  showed  that  the  model  was  indeed  performing  as 
theoretically  expected  and  that  it  was  capable  of  accommodating  a  large, 
complex  and  diversified  network.  No  output  analysis,  particularly  an 
analysis  of  delays  could  be  carried  out,  however,  since  the  model's  input 
data  were  hypothetical  and  since  comparative  real-world  data  on  performance 
was  also  lacking.  Such  data  can  be  obtained  from  various  sources  including 
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the  Corps  of  Engineers,  the  St.  Lawrence  Seaway  Development  Corporation, 
the  St.  Lawrence  Seaway  Authority,  port  authorities  and  waterway  operators, 
and  Indeed  their  availability  Is  a  prerequisite  to  the  use  of  the  model. 

Because  of  this  problem  more  stable  variables  for  which  data  are  avail¬ 
able,  such  as  tonnage  flows,  must  be  used  to  compare  simulation  output  with 
real-world  data.  This  comparison  may  be  of  the  form  shown  in  Table  5  where 
the  results  from  the  uncalibrated  simulation  run  are  compared  with  the  actual 
input  data.  The  difference  column  Indicates  that  the  relationships  balancing 
supply  and  demand  Incorporated  in  NETSIM  II 's  structure  produced  tonnage 
flows  which  lay  somewhere  along  the  desired  levels  (based  upon  hypothetical 
data).  With  the  benefit  of  an  accurate  data  base,  the  model  can  be  properly 
calibrated  for  the  GL-SLS  system  and  rigorous  statistical  tests  can  be  used 
to  analyze  the  output, 

A  number  of  output  statistics  can  be  used  to  aid  the  calibration  process. 
Some  calibration  parameters  are  already  built  into  the  model  as  discussed 
previously  in  subsection  E  of  Section  II.  Alternately,  the  model  output 
might  be  statistically  adjusted  to  reflect  modeling  error.  Figure  11  shows 
some  of  the  output  statistics  generated  by  the  NETSIM  II-PROSIM  model  and 
this  also  serves  to  Illustrate  the  additional  Information  provided  by  the 
extended  model  vis-a-vis  its  predecessor,  NETSIM  I. 

3.  Future  Model  Studies 

Having  outlined  the  type  of  output  available  from  the  GL-SLS  simulation 
run,  it  Is  traditional  to  focus  upon  the  limitations  of  the  model  and 
recommend  further  studies.  In  the  case  of  the  NETSIM  II-PROSIM  model.  It 
it  Indeed  crucial.  In  order  to  have  meaningful  applications,  to  gather  real- 
world  data  not  only  on  the  model's  input  needs  but  also  on  some  of  the 


TABLE  5.  OUTPUT  TONNAGE  SU^®lARY  FOR  GL-SLS  SIMULATION  RUN 


Port 

0-D  Tons 

Simulated  Tons 

Percent  Change* 

Duluth 

5,200,883 

5,094,500 

2.0 

Marquette 

314,023 

308,200 

1.9 

Es canaba 

1,470,171 

1,809,000 

-23.0 

Milwaukee 

70,346 

64,100 

8.9 

Chicago 

1,124,133 

1,401,100 

-24.6 

Gary 

554,794 

579,300 

-  4.4 

Muskegon 

439,590 

467,900 

-  6.4 

Alpena 

2,904,255 

3,433,500 

-18.2 

Detroit 

101,862 

95,400 

6.3 

Toledo 

1,828,364 

1,285,400 

29.  7 

Cleveland 

2,000,054 

2,349,300 

-17.5 

Buffalo 

37,587 

33,200 

11.7 

Inland 

Waterways 

16,112 

0 

100.0** 

U.S.  Coastwise 

39,546 

28,500 

27.9 

Hamilton 

426,837 

227,600 

31.4 

Toronto 

555,540 

361,700 

34.9 

Montreal 

14,310 

10,700 

25.2 

Atlantic 
(Ove rseas) 

286.582 

.  it’k'k 

Total  (exclud¬ 
ing  Atlantic) 

17,098,407 

17,549,400 

2.6 

*Perc«2nt  Change  is  difference  from  the  true  value. 

**k  shipment  large  enough  to  transport  not  available  during  most 
of  the  simulation. 

***No  statistics  were  gathered  for  Atlantic  since  the  saltwater 
vessels  were  removed  from  systems  upon  arrival  at  the  node. 

Mote:  Error  Is  large  for  ports  with  relatively  high  proportion  of 
overseas  cargo. 
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output  parameters.  These  data  should  be  used  to  validate  further  the 
model  and  also  to  calibrate  It  for  the  system  of  interest.  A  list  of 
some  of  the  relevant  exercises  follows. 

With  regard  to  validation: 

a.  steady  state  attainment  for  locks — l.e.,  how  much  warmup 
time  Is  necessary  for  the  locks  to  achieve  a  stable 
behavior? 

b.  steady  state  attainment  for  ports  and  other  system  elements, 

c.  output  error  analysis  (tonnage  and  vessel  flows,  delays, 
transit  times). 

With  regard  to  calibration: 

a.  handling  of  parallel  lock  systems  such  as  at  Sault  Ste.  Marie, 

b.  proper  timing  of  bl-dlrectlonal  traffic, 

c.  timing  cargo  arrivals  at  ports, 

d.  determination  of  stable  values  for  the  model's  built-in 
calibration  factors, 

e.  port  statistics  analysis — how  accurately  must  port  facilities 
and  their  capabilities  be  represented? 

f.  vessel  movement  analysis. 

The  above  suggestions  are  made  In  an  effort  to  describe  areas  which  may 
be  improved  to  enhance  the  efficiency  of  the  model.  For  example,  in 
reference  to  steady  state  attainment,  considerable  time  savings  could  be 
realized  in  repeated  simulation  experiments  if  the  minimum  warmup  time  for 
various  system  conditions  could  be  statistically  determined;  however,  such 
a  determination  Is  not  a  prerequisite  to  the  use  of  the  model.  Again,  the 
model's  calibration  factors  could  be  set  intuitively  at  "safe"  levels;  yet, 
this  may  be  Inefficient  and  unnecessary. 


C.  Other  Potential  Applications 


The  purpose  of  this  section  Is  to  address  the  question  pf  whether 
the  NETSIM  II-PROSIM  simulation  model  can  be  used  to  analyze  the  character¬ 
istics  of  other  waterway  systems.  Clearly,  the  model  has  been  designed 
for  the  GL-SLS  navigation  system,  whether  it  be  the  total  system  or  a  sub¬ 
system  such  as  the  Sault  Ste,  Marie  locks.  Can  the  model  be  applied  then 
to  other  navigation  systems  such  as  the  Inland  waterways? 

If  the  question  is  whether  the  model  can  be  applied  as  is  to  other 
waterways,  the  answer  is  definitely  not.  NETSIM  II-PROSIM  has  been  specifi¬ 
cally  tailored  to  the  GL-SLS  system  and  in  fact,  takes  advantage  of  the 
system's  specific  characteristics  in  its  program  structure.  Applying  the 
model  to  a  waterway  system  with  different  operating  characteristics  can 
only  lead  to  erroneous  results. 

However,  if  the  question  is  whether  the  model  provides  a  basic  capa¬ 
bility  for  simulation  studies  of  other  waterways,  then  there  is  indeed  much 
logic  that  is  transferraHe.  The  lock,  reach,  Monte  Carlo  Sampling  and 
vessel  handling  logic  could  be  used  for  a  simulation  on  the  inland  waterways, 
for  example,  even  though  the  vessel  entity  itself  has  a  separate  definition. 
Changing  NETSIM  II-PROSIM  for  other  waterways  is  not  a  simple  task  and 
should  be  undertaken  only  after  becoming  thoroughly  familiar  with  all 
aspects  of  the  program. 


VI.  CONCLUSIONS 


As  stated  in  Section  I,  the  objective  of  this  entire  simulation  effort 
was  the  development  of  an  analytical  tool  suitable  for  exploring  the 
operating  characteristics  of  the  Great  Lakes-St.  Lawrence  Waterway  System. 

The  preceding  five  sections  of  this  report  have  served  to  document  in 
summary  form  the  data  needs,  structure  and  the  output  of  the  NETSIM  II-PROSIM 
computer  simulation  model.  Coupled  with  the  previous  works  on  the  inland 
waterways  at  Penn  State,  this  effort  provides  the  Corps  of  Engineers  with  a 
set  of  shallow  and  deep  draft  navigation  models  which  can  be  applied  to  a 
wide  variety  of  waterway  transportation  problems. 

The  potential  applications  for  the  NETSIM  II-PROSIM  model  Involve  pri¬ 
marily  investigations  into  the  Impact  of  potential  structural  and  nonstructural 
Improvements.  Typical  Issues  that  may  be  addressed  by  the  model  Include: 

-  Given  current  and  future  traffic  forecasts,  what  is  the  capacity 

of  the  waterway  system?  What  and  where  are  the  constraints? 

Wliat  methods  can  be  suggested  to  alleviate  the  constraints? 

-  What  locks  or  lock  subsystems  need  to  be  improved?  In  what 

manner?  When?  In  what  sequence?  What  are  the  benefits  in 
terms  of  reduced  delay  and  transit  time? 

-  How  can  system  efficiency  be  improved?  Alternative  locking  rules? 

Artificial  navigation  aids?  Channel  deepening?  To  what  extent 
ran  the  fleet  evolve  to  service  a  given  flow  of  commodities 
vjlthin  the  existing  system? 

-  How  will  changes  In  future  fleet  composition,  commodity  movements, 

different  facility  locations,  ship  scheduling  procedures,  dock 
strikes,  etc.,  affect  system  parameters? 
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-  How  will  season  extension  affect  the  pattern  of  cargo  movements 

and  facility  and  fleet  utilization? 

-  What  would  be  the  effect  of  staging  the  closing  of  the  season  so 

individual  ports,  channels  and  lakes  would  close  at  substantially 

different  times? 

-  How  does  channel  depth  affect  ship  cargo  capacity,  vessel  speed 

and  hence,  the  pattern  of  vessel  movements? 

To  conduct  research  into  some  of  the  areas  mentioned  above  might 
require  modest  cb^ftiges  in  the  model  to  fit  the  particular  need.  For 
example,  investigations  i  .to  the  affects  of  various  locking  rules  will 
necessitate  insertion  of  the  appropriate  locking  rule  logic  in  the  lock 
module.  This  is  because  the  model  could  not  possibly  accommodate  all  pos¬ 
sible  investigations  on  a  ready-to-go-basis.  However,  NETSIM  II-PROSIM 
does  provide  the  basic  capability  for  general  purpose  simulations.  It  has 
been  programmed  in  a  modular  fashion  just  for  this  purpose  of  providing 
flexibility  so  that  incorporating  different  locking  rules  need  not  affect 
the  logic  for  the  port,  reach,  lake  and  support  routines.  This  illustrates 
another  major  point  about  complex  simulation  models  such  as  the  current 
effort.  Simulation  capability  for  the  GL-SLS  system  as  for  the  inland 
waterways  and  any  ot’;  er  case  is  a  continuous  undertaking  since  it  would  be 
folly  to  assume  that  the  system  interactions  that  are  the  object  of  simula¬ 
tion  will  forever  remain  static.  There  is  an  implied  responsibility  to 
reassess  model  parameters  periodically  and  to  evaluate  the  validity  of  the 
model  in  the  future  as  the  requisite  data  become  available. 
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